消息不多发不少发

消息可靠传输代表了两层意思，既不能多也不能少。

为了保证消息不多，也就是消息不能重复，也就是生产者不能重复生产消息，或點消费者不能重复消费消息

首先要确保消息不多发，这个不常出现，也比较难控制，因为如果出现了多发，很大的原因是生产者自己的原因，如果要避免出现问题，就需要在消费端做控制

要避免不重复消费，最保险的机制就是消费者实现幂等性，保证就算重复消费，也不会有问题，通过幂等性，也能解决生产者重复发送消息的问题

消息不能少，意惠就是消息不能丢失，生产者发送的消息，消费者一定要能消费到，对于这个问题，就要考虑两个方面

a.生产者发送消息时，要确认broker确实收到井持久化了这条消息，比如RabbitMQ的confirm机制，Kafka的ack机制都可以保证生产者能正确的将消息发送给broker b. broker要等待消费者真正确认消费到了消息时才删除掉消息，这里通第就是消费端ack机制，消费者接收到一条消息后，如果确认没问题了，就可以给broker发送一个ack, broker接收到ack后才会删除消息

消息队列有哪些作用

解糯：使用消息队列来作为两个系统之间的通讯方式，两个系統不需要相互依赖了 2．异步：系统A给消费队列发送完消息之后，就可以继续做其他事情了 3.流量削峰：如果使用消息队列的方式来调用某个系統，那么消息将在队列中排队，有消费者自己控制消费速度死信队列是什么？延时队列是什么？
死信队列也是一个消息队列，它是用来存放那些没有成功消费的消息的，通常可以用来作为消息重试
延时队列就是用来存放需要在指定时间被处理的元素的队列，通常可以用来处理一些具有过期性操作的业务，比如十分钟内未支付则取消订单 Kafka为什么比RocketMQ的吞吐量要高 Kafka的生产者采用的是异步发送消息机制，当发送一条消息时，消息并没有发送到Broker而是缓存起来，然后直接向业务返回成功，当缓存的消息达到一定数量时再批量发送给Broker。这种做法减少了网络io，从而提高了消息发送的吞吐量，但是如果消息生产者宕机，会导致消息丢失，业务出错，所以理论上kafka利用此机制提高了性能却降低了可靠性。

幂等行

如果是 redis，反正每次粉基 set，天然幂等性

生产者发送消息时携带一个全局唯的id到费者拿到消息后。先根据这个id去 recis里查一下，之前有没消藝过。设有消惠过就处理，井且写入这个 id到redis，如果消麵过了，期不处理。

基于mysql的唯一主键